In io.Connect Desktop: if true, the platform will add CPU, memory, and OS information to the resource attributes of the published signals.

Additional properties to publish as part of each OpenTelemetry signal, specified as key/value pairs. You can use environment variables as values. Environment variables must start and end with a percent sign (e.g., %MyEnvVar%), and can contain a fallback value (e.g., %MyEnvVar?DefaultValue%).

Additional properties to publish as part of the OpenTelemetry resource definition for all OpenTelemetry signals, specified as key/value pairs. You can use environment variables as values. Environment variables must start and end with a percent sign (e.g., %MyEnvVar%), and can contain a fallback value (e.g., %MyEnvVar?DefaultValue%).

Whether to add resource attributes to signal attributes.

Application name to use in telemetry information. By default, it's populated by io.Connect.

Whether library is enabled. If disabled, API is still usable, but methods are no-ops.

If true, the library will swallow all errors, instead of propagating them.

If failure to initialize library will throw upstream error.

Interval in milliseconds to wait for any remaining telemetry data to be exported during shutdown of the platform.

This is the maximum awaiting interval and the platform may shutdown before it expires if all telemetry data has already been published.

If 0, the final export is fire-and-forget: it is started - which also ends, and thereby publishes, the spans that are still open - but the shutdown doesn't wait for it, so only what makes it out before the process exits is published. On an abnormal exit of the platform, lastChanceExportOnError.exportTimeoutMs is used instead.

Additional headers to send in HTTP requests, e.g. when using HTTP exporters.

In io.Connect Desktop, gets the telemetry describing an abnormal exit out before the platform exits: a startup error, an unhandled error (crash) at any later point, an exit with an error code, or a shutdown before the startup has completed (restarts excluded). The final export waits for up to LastChanceExportOnErrorSettings.exportTimeoutMs instead of finalExportTimeoutMs, and - with a late initialization (lateInit) - io.Insights is initialized after all, within LastChanceExportOnErrorSettings.initTimeoutMs, when the platform goes down before it was, so the telemetry buffered so far, the error included, still gets published.

true (the default) uses the default settings; an object configures them; false switches it off - an abnormal exit then waits for the final export as long as a normal one would, and telemetry buffered before a late initialization is lost.

In io.Connect Desktop, initializes io.Insights late in the startup - right after the SSO authentication has completed (see LateInitSettings.initStage) - rather than as early as possible. The startup telemetry gathered until then is buffered and published once io.Insights is initialized.

Early initialization makes the startup trace richer and helps telemetry be published even in the case of an early startup error; a late one lets a "pre-sso" autoStart application provide additional OTEL attributes at runtime before io.Insights gets initialized (see LateInitSettings.attributesTimeoutMs), and lets the platform's own export requests carry the SSO login from the first one on (see ssoAuth).

true switches it on with the default settings; an object also configures it. Has no effect when io.Insights is disabled.

If the library should log the settings used to initialize it.

If provided, this value will be added to the metrics and span attributes and to the span filtering context (see 'filters' in TracesSettings).

Whether the library should register its own instances of the OTEL SDK global objects, e.g. MeterProvider. This is useful for controlling which instance of the SDK is used, in applications that initialize their own SDK.

If true, the io.Insights library will register its own OTEL SDK global object instances if none are already registered. This means an already initialized SDK will be used in preference to the one initialized by io.Insights.

If "force", the io.Insights library will register its own OTEL SDK global object instances unconditionally, regardless of any existing registrations. This means any already initialized SDK will not be used and the library will always use its own instance.

If false, the io.Insights library will not register its own OTEL SDK global object instances. The library will require an already initialized OTEL SDK instance.

For Node applications: whether to attempt to request io.Insights settings from the platform when initializing;

If provided, this value will be added to the metrics and traces service.instance.id attribute, unless an OTEL service object (e.g. TraceProvider) has been provided to the library with a different setting.

If provided, this value will be added to the metrics and traces service.name attribute, unless an OTEL service object (e.g. TraceProvider) has been provided to the library with a different setting.

If provided, this value will be added to the metrics and traces service.version attribute, unless an OTEL service object (e.g. TraceProvider) has been provided to the library with a different setting. attribute.

Settings for injecting the io.Connect SSO login information into the headers of the OpenTelemetry export requests. Can be overridden for the traces, the metrics and the logs in their own settings. See SSOAuthSettings.

Suppress double initialization warnings from the OTEL SDK.

If true, io.Insights publishes through the host application's own OTEL SDK instead of building providers of its own: the tracer, meter and logger providers are taken from the OTEL API globals unconditionally (the globals are never absent - unregistered APIs return proxy/noop providers, so there is no meaningful fallback).

Ordering matters: the trace and logs globals are proxies that late-bind, so signals emitted before the host registers its SDK are dropped and start flowing once it does; the metrics global is a snapshot, which io.Insights compensates for by re-resolving it per meter creation - but meters created before the host registered stay bound to the noop. Register the host SDK before initializing io.Insights for full coverage.

In this mode io.Insights registers nothing: registerGlobalOTELObjects is effectively ignored, the global propagator is whatever the host registered (header injection rides it), resource attributes come from the host's providers (io.Insights resource settings are unused), and waitForFinalExport is best-effort - flushing on shutdown is the host SDK's responsibility.

If provided, this value will be added to the metrics and traces user.id attribute, unless an OTEL service object (e.g. TraceProvider) has been provided to the library with a different setting.